【セッションレポート】DevOps in Action #cmdevio2015E

Developers.IO 2015

#イベント

#イベントレポート

quiver

2015.04.13

この記事は公開されてから1年以上経過しています。情報が古い可能性がありますので、ご注意ください。

セッション概要

irbbbです。2015年3月29日に開催された Developers.IO 2015 にて、アマゾンデータサービスジャパン株式会社の今井雄太様に『DevOps in Action』というタイトルで、アマゾンのお客様や海外の「面白い」「感心した」DevOpsっぽい事例を発表していただきました。カジュアルな話かとおもいきや、かなりディープが話がてんこ盛りでした。

本セッションは撮影禁止のため、文章だけのレポートとなります。

当日のスライドはこちらからダウンロード願います。

NetflixのSOAとデプロイについて

Netflixは全米VOD市場で35％のシェアを持つトップ企業

SOAについて

Service-oriented architecture(SOA)を採用し、サービスごとに独立して開発できる。 APIの互換性が保たれる限り、リリースやリファクタリングはサービスの開発チームに委譲できる。

ビルドパイプライン

sbtでビルドして.warファイル化
Gradleで.debファイル化
animator(Netflix製のPackerのようなツール)で.amiファイル化

このビルドパイプラインがこgitへのコミットごとに走り、任意のリビジョンに対して対応するamiを指定してテストやデプロイが可能になっている。

gitのdevelopブランチにpushしたコードは、テストが成功すると自動的にmasterにマージされ、ビルドパイプラインが走ってデプロイされる!

デプロイにはNetflix製のAsgardを使っている。 blue-greenデプロイの思想でautoscaleグループを旧インスタンス群から新インスタンス群に切り替える。

NetflixのOSSへの取り組みいついて

NetflixはopsツールのOSS開発に積極的。 Netflixからzerotodockerというツールが提供され、docker環境があれば簡単に手元で試せるようになっている。

世界展開するマルチプレイヤーゲームのレイテンシとの戦い

クライアントとサーバの物理的な距離があると、FPSゲームはラグラグになってしまう。例えば、大陸をまたぐとレイテンシは100msを超える

クライアントには中央サーバーに一度アクセスさせ、最寄りのゲームサーバーに振る。ゲームデータもAmazon CloudFrontでエッジサーバから配信する

クライアントとゲームサーバはソケットを張りっぱなしなので、ELBを介さずに直接サーバーに接続する。サーバはAWS CloudFormationとChefで環境構築。ゲーム終了後はゲームログを中央サーバに送信する。

新しいゲームサーバが追加されると中央サーバーに通知・登録される。中央サーバは各リージョンに通信すれば、PODの状態がわかる。サーバの増減も中央からPODに命令される。

NEXONのMMORPGへの取り組み

従来のMMORPGは1個のサーバ(やプロセス)にワールドを閉じ込める手法がよく使われてきた。

ゲーム内で距離が離れたプレイヤー同士はゲーム内でインタラクションがないと考え、遠くはなれた領域はサーバを分けてしまった。 1サーバが処理するワールド領域の広さはユーザーの混み具合によって異なる。狭い領域であっても、ユーザーが増えて混みすぎるとサーバを動的に分割し、一定ユーザを新サーバに順次再接続するよう振り分ける。

ユーザーデータはサーバ間で同期させる。

GraniのDevOpsへの取り組み

AWS事例では珍しく

IIS8(Windows Server 2012)
C#

と.NET系環境で動いている。

パフォーマンスへのこだわりが強い。Time To First Byte(TTFB)も同業他社に比べて早い。インフラチームはアプリケーションレイヤーの運用を楽にするツールをたくさん作っている。アプリケーションの処理をフックし、あらゆるログを取得している。 SQLも自動で実行計画がロギングされ、改善余地のあるものは通知される。手動運用にすると結局誰もやらなくなる。